FIG. 1 is a schematic diagram of policy and charging control (PCC) architecture defined in the 3rd Generation Partnership Project (3GPP). As shown in FIG. 1, a policy and charging rules function (PCRF) enacts a Quality of Service (QoS) and charging policy for network resources used by traffic. To enact the above control policy, the PCRF needs to consider traffic information received from an application function (AF), user subscription information received from a subscription profile repository (SPR) and a policy configured by an operator, and the like. The PCRF sends the control policy made for the traffic to a policy and charging enforcement function (PCEF) or a bearer binding and event report function (BBERF) for implementation. Meanwhile, the PCRF may subscribe to events related to a bearer layer from the PCEF and/or the BBERF so that the PCRF can timely perceive the events and change the control policy when the events happen on the bearer layer. In addition, the PCEF and a traffic detection function (TDF) can perform an application detection and control function according to a PCC rule (PCEF) or an application detection and control (ADC) rule sent by the PCRF, which further includes an online charging system (OCS), an offline charging system (OFCS), and communication interfaces between modules such as Rx, Nt, Sp, Gxx and the like.
The AF allocate resources of a network layer to the application by providing the traffic information to the PCRF and requesting the QoS authorization of the network. FIG. 2 is a flowchart in which an AF requests a network QoS guarantee. The process includes the steps described below.
In step 201, the AF provides the traffic information to the PCRF. The traffic information is carried in a message, which includes a media description component (carried in a Media-Component-Description AVP).
An authentication and authorization request (AAR) message sent by the AF to the PCRF for providing the traffic information has a format below. One AAR message may include zero media description component, one media description component, or multiple media description components.
<AA-Request>::=<Diameter Header: 265, REQ, PXY>                <Session-Id>        {Auth-Application-Id}        {Origin-Host}        {Origin-Realm}        {Destination-Realm}        [Destination-Host]        [IP-Domain-Id]        [Auth-Session-State]        [AF-Application-Identifier]        [Media-Component-Description]        [Service-Info-Status]        [AF-Charging-Identifier]        [SIP-Forking-Indication]        [Specific-Action]        [Subscription-Id]        [Supported-Features]        [Reservation-Priority]        [Framed-IP-Address]        [Framed-Ipv6-Prefix]        [Called-Station-Id]        [Service-URN]        [Reference-Id]        [Origin-State-Id]        *[Proxy-Info]        *[Route-Record]        *[AVP]        
The Media-Component-Description AVP has a format below. One Media-Component-Description AVP includes zero Media-Sub-Component AVP, one Media-Sub-Component AVP, or multiple Media-Sub-Component AVPs. The Media-Component-Description is identified by a Media-Component-Number.
Media-Component-Description::=<AVP Header: 517>                {Media-Component-Number}; Ordinal number of the media comp.        *[Media-Sub-Component]; Set of flows for one flow identifier        [AF-Application-Identifier]        [Media-Type]        [Max-Requested-Bandwidth-UL]        [Max-Requested-Bandwidth-DL]        [Max-Supported-Bandwidth-UL]        [Max-Supported-Bandwidth-DL]        [Min-Desired-Bandwidth-UL]        [Min-Desired-Bandwidth-DL]        [Min-Requested-Bandwidth-UL]        [Min-Requested-Bandwidth-DL]        [Flow-Status]        [Priority-Sharing-Indicator]        [Reservation-Priority]        [RS-Bandwidth]        [RR-Bandwidth]        *[Codec-Data]        [Sharing-Key-DL]        [Sharing-Key-UL]        *[AVP]        
The Media-Sub-Component AVP has a format below. A Flow-Number is used for identifying a Media-Sub-Component.
Media-Sub-Component::=<AVP Header: 519>                {Flow-Number}; Ordinal number of the IP flow        0*2[Flow-Description]; UL and/or DL        [Flow-Status]        [Flow-Usage]        [Max-Requested-Bandwidth-UL]        [Max-Requested-Bandwidth-DL]        [AF-Signalling-Protocol]        [ToS-Traffic-Class]        *[AVP]        
In step 202, the PCRF stores the traffic information and returns an acknowledgement message.
In step 203, the PCRF makes a policy decision and makes a PCC rule according to a network policy, the traffic information and the user subscription information etc. In this process, the PCRF may need to interact with the SPR and acquire the user subscription information.
In step 204, the PCRF provides the PCC rule made after the policy decision to the PCEF.
In step 205, the PCEF returns an acknowledgement message after installing the PCC rule.
In step 206, the PCEF initiates a resource reservation process according to the PCC rule.
In step 207, after the PCRF provides the PCC rule to the PCEF (the step 204), the PCRF receives updated traffic information which carries updated media description component.
In step 208, the PCRF stores the updated traffic information and returns an acknowledgement message.
In step 209, the PCRF makes the policy decision and updates the previous PCC rule according to the network policy, the traffic information and the user subscription information etc.
In step 210, the PCRF provides the updated PCC rule to the PCEF.
In step 211, the PCEF returns an acknowledgement message after installing the PCC rule.
In step 212, the PCEF initiates the resource reservation process according to the installed PCC rule.
In step 213, the PCEF receives a response message of the resource reservation process initiated in step 206 which indicates a resource reservation failure.
In step 214, the PCEF sends an event notification to the PCRF, where the event notification carries a resource reservation failure indication and a corresponding PCC rule name.
In step 215, the PCRF returns an acknowledgement message to the PCEF.
In step 216, the PCRF sends the event notification to the AF, where the event notification carries the resource reservation failure indication and a flow identifier.
The PCEF sends the event notification to the PCRF through an RAR message. The RAR message has a format below. A Specific-Action AVP is used for carrying the resource reservation failure indication and a Flows AVP is used for carrying the flow identifier.
<RA-Request>::=<Diameter Header: 258, REQ, PXY>                <Session-Id>        [DRMP]        {Origin-Host}        {Origin-Realm}        {Destination-Realm}        {Destination-Host}        {Auth-Application-Id}        *{Specific-Action}        *[Access-Network-Charging-Identifier]        [Access-Network-Charging-Address]        [AN-Trusted]        *[Flows]        *[Subscription-Id]        [Abort-Cause]        [IP-CAN-Type]        [NetLoc-Access-Support]        [RAT-Type]        [Sponsored-Connectivity-Data]        [3GPP-User-Location-Info]        [User-Location-Info-Time]        [3GPP-MS-TimeZone]        *[RAN-NAS-Release-Cause]        [3GPP-SGSN-MCC-MNC]        [TWAN-Identifier]        [UE-Local-IP-Address]        [Origin-State-Id]        *[Class]        *[Proxy-Info]        *[Route-Record]        *[AVP]        
The Flows AVP has a format below. Media-Component-Number is used for identifying an IP flow.
Flows::=<AVP Header: 510>                {Media-Component-Number}        *[Flow-Number]        [Final-Unit-Action]        *[AVP]        
In step 217, the AF returns an acknowledgement message to the PCRF.
In the above process, the AF receives the resource reservation failure feedback after sending the updated traffic information to the PCRF, so the AF cannot determine whether the resource reservation corresponding to the initially provided traffic information fails or the resource reservation corresponding to the updated traffic information fails. Similarly, the PCRF receives the resource reservation failure feedback after providing the updated PCC rule to the PCEF, so the PCRF cannot determine whether the resource reservation corresponding to the initially provided PCC rule fails or the resource reservation corresponding to the updated PCC rule fails.
The above problem also exists in the case where the AF continuously updates the traffic information for multiple times after an initial resource reservation succeeds. When the resource reservation corresponding to one traffic information updating fails, the AF cannot know which traffic information updating corresponds to the failed resource reservation.
Accordingly, the AF cannot know a successful resource reservation corresponds to which traffic information updating.